home *** CD-ROM | disk | FTP | other *** search
xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) NNNNAAAAMMMMEEEE xfsdump - XFS filesystem incremental dump utility SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS xxxxffffssssdddduuuummmmpppp -h xxxxffffssssdddduuuummmmpppp [ options ] -f _d_e_s_t [ -f _d_e_s_t ... ] _f_i_l_e_s_y_s_t_e_m xxxxffffssssdddduuuummmmpppp [ options ] - _f_i_l_e_s_y_s_t_e_m xxxxffffssssdddduuuummmmpppp -I [ subopt=value ... ] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _x_f_s_d_u_m_p backs up files and their attributes in a filesystem. The files are dumped to storage media, a regular file, or standard output. Options allow the operator to have all files dumped, just files that have changed since a previous dump, or just files contained in a list of pathnames. The _x_f_s_r_e_s_t_o_r_e(1M) utility re-populates a filesystem with the contents of the dump. Each invocation of _x_f_s_d_u_m_p dumps just one filesystem. That invocation is termed a dump session. The dump session splits the filesystem into one or more dump streams, one per destination. The split is done in filesystem inode number (ino) order, at boundaries selected to equalize the size of each stream. Furthermore, the breakpoints between streams may be in the middle of very large files (at extent boundaries) if necessary to achieve reasonable stream size equalization. Each dump stream can span several media objects, and a single media object can contain several dump streams. The typical media object is a tape cartridge. The media object records the dump stream as one or more media files. A media file is a self-contained partial dump. The portion of a dump stream contained on a media object can be split into several media files. This minimizes the impact of media dropouts on the entire dump stream, and speeds subtree restores. _x_f_s_d_u_m_p maintains an online dump inventory in /_v_a_r/_x_f_s_d_u_m_p/_i_n_v_e_n_t_o_r_y. The ----IIII option displays the inventory contents hierarchically. The levels of the hierarchy are: filesystem, dump session, stream, and media file. The options to _x_f_s_d_u_m_p are: ----aaaa Specifies that files for which the Data Migration Facility (DMF) has complete offline copies (dual-state files) be treated as if they were offline (OFL). This means that the file data will not be dumped by xfsdump, resulting in a smaller dump file. If the file is later restored the file data is still accessible through DMF. If both option -a and '-z option' are specified, '-a option' takes precedence (see '-z option' below). ----bbbb _b_l_o_c_k_s_i_z_e Specifies the blocksize to be used for the dump. This option is specified only with the minimal rmt option (see the ----mmmm option below). For a QIC drive , blocksize must always be 512. For other drives such as DAT or 8 mm , a blocksize of 245760 bytes works well. PPPPaaaaggggeeee 1111 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) The same blocksize must be specified to restore the tape. When specified , this blocksize applies to all remote tape destinations. ----cccc _p_r_o_g_n_a_m_e Use the specified program to alert the operator when a media change is required. The alert program is typically a script to send a mail or flash a window to draw the operator's attention. ----dddd _f_i_l_e_s_i_z_e Specifies the size, in megabytes, of dump media files. xfsdump will dump data to tape in one or more media files. It will attempt to estimate the ideal media file size based on the tape device being used, and the amount of data to be written. The media file size may need to be adjusted if, for example, xfsdump cannot fit a media file onto a single tape. ----eeee Allow files to be excluded from the dump. This will cause xfsdump to skip those files which are tagged with the "SGI_XFSDUMP_SKIP_FILE" attribute. Without this flag, xfsdump will ignore the attribute, and continue to dump affected files. ----ffff _d_e_s_t [ ----ffff _d_e_s_t ... ] Specifies a dump destination. A dump destination can be the pathname of a device (such as a tape drive), a regular file, or a remote tape drive (see _r_m_t(1M)). Up to 20 dump destinations can be specified, in which case each destination receives an equal portion of the filesystem. This option must be omitted if the standard output option (a lone ---- preceding the source filesystem specification) is specified. ----llll _l_e_v_e_l Specifies a dump level of 0 to 9. The dump level determines the base dump to which this dump is relative. The base dump is the most recent dump at a lesser level. A level 0 dump is absolute - all files are dumped. A dump level where 1 <= _l_e_v_e_l <= 9 is referred to as an incremental dump. Only files that have been changed since the base dump are dumped. Subtree dumps (see the ----ssss option below) cannot be used as the base for incremental dumps. ----mmmm Use the minimal rmt protocol for remote tape destinations. This is used when the remote machine is a non-SGI machine. With this option, _x_f_s_d_u_m_p uses version 1 rmt protocol for all remote tape drives. This option cannot be used without specifying a blocksize to be used (see ----bbbb option above). If all rmt destinations are SGI machines, it is preferable nnnnooootttt to specify this option. ----oooo Overwrite the tape. With this option, _x_f_s_d_u_m_p does not read the tape first to check the contents. This option may be used if _x_f_s_d_u_m_p is unable to determine the block size of a tape . PPPPaaaaggggeeee 2222 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) ----pppp _i_n_t_e_r_v_a_l Causes progress reports to be printed at the specified interval. _i_n_t_e_r_v_a_l is given in seconds. The progress report indicates how many files have been dumped, the total number of files to dump, the percentage of data dumped, and the elapsed time. ----ssss _p_a_t_h_n_a_m_e [ ----ssss _p_a_t_h_n_a_m_e ... ] Restricts the dump to files contained in the specified pathnames (subtrees). Up to 100 pathnames can be specified. A _p_a_t_h_n_a_m_e must be relative to the mount point of the filesystem. For example, if a filesystem is mounted at /_d_2, the _p_a_t_h_n_a_m_e argument for the directory /_d_2/_u_s_e_r_s is ``users''. A _p_a_t_h_n_a_m_e can be a file or a directory; if it is a directory, the entire hierarchy of files and subdirectories rooted at that directory is dumped. Subtree dumps cannot be used as the base for incremental dumps (see the ----llll option above). ----vvvv _v_e_r_b_o_s_i_t_y ----vvvv _s_u_b_s_y_s=_v_e_r_b_o_s_i_t_y[,_s_u_b_s_y_s=_v_e_r_b_o_s_i_t_y,...] Specifies the level of detail used for messages displayed during the course of the dump. The _v_e_r_b_o_s_i_t_y argument can be passed as either a string or an integer. If passed as a string the following values may be used: ssssiiiilllleeeennnntttt, vvvveeeerrrrbbbboooosssseeee, ttttrrrraaaacccceeee, ddddeeeebbbbuuuugggg, or nnnniiiittttttttyyyy. If passed as an integer, values from 0-5 may be used. The values 0-4 correspond to the strings already listed. The value 5 can be used to produce even more verbose debug output. The first form of this option activates message logging across all dump subsystems. The second form allows the message logging level to be controlled on a per-subsystem basis. The two forms can be combined (see the example below). The argument _s_u_b_s_y_s can take one of the following values: ggggeeeennnneeeerrrraaaallll, pppprrrroooocccc, ddddrrrriiiivvvveeee, mmmmeeeeddddiiiiaaaa, iiiinnnnvvvveeeennnnttttoooorrrryyyy, iiiinnnnoooommmmaaaapppp and eeeexxxxcccclllluuuuddddeeeedddd____ffffiiiilllleeeessss. For example, to dump the root filesystem with tracing activated for all subsystems: #### xxxxffffssssdddduuuummmmpppp ----vvvv ttttrrrraaaacccceeee ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// To enable debug-level tracing for drive and media operations: #### xxxxffffssssdddduuuummmmpppp ----vvvv ddddrrrriiiivvvveeee====ddddeeeebbbbuuuugggg,,,,mmmmeeeeddddiiiiaaaa====ddddeeeebbbbuuuugggg ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// To enable tracing for all subsystems, and debug level tracing for drive operations only: #### xxxxffffssssdddduuuummmmpppp ----vvvv ttttrrrraaaacccceeee,,,,ddddrrrriiiivvvveeee====ddddeeeebbbbuuuugggg ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// To list files that will be excluded from the dump: #### xxxxffffssssdddduuuummmmpppp ----eeee ----vvvv eeeexxxxcccclllluuuuddddeeeedddd____ffffiiiilllleeeessss====ddddeeeebbbbuuuugggg ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// PPPPaaaaggggeeee 3333 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) ----zzzz _s_i_z_e Specifies the maximum size, in kilobytes, of files to be included in the dump. Files over this size will be excluded from the dump, except for DMF dual-state files when '-a option' is specified (see '-a option' above). When specified, '-a option' takes precedence over '-z option'. The size is an estimate based on the number of disk blocks actually used by the file, and so does not include holes. In other words, size refers to the amount of space the file would take in the resulting dump. On an interactive restore, the skipped file is visible with xfsrestore's 'ls' and while you can use the 'add' and 'extract' commands, nothing will be restored. ----AAAA Do not dump extended file attributes. When dumping a filesystem managed within a DMF environment this option should not be used. DMF stores file migration status within extended attributes associated with each file. If these attributes are not preserved when the filesystem is restored, files that had been in migrated state will not be recallable by DMF. Note that dumps containing extended file attributes cannot be restored with older versions of _x_f_s_r_e_s_t_o_r_e(1M). ----BBBB _s_e_s_s_i_o_n__i_d Specifies the ID of the dump session upon which this dump session is to be based. If this option is specified, the ----llll (level) and ----RRRR (resume) options are not allowed. Instead, xxxxffffssssdddduuuummmmpppp determines if the current dump session should be incremental and/or resumed, by looking at the base session's level and interrupted attributes. If the base session was interrupted, the current dump session is a resumption of that base at the same level. Otherwise, the current dump session is an incremental dump with a level one greater than that of the base session. This option allows incremental and resumed dumps to be based on any previous dump, rather than just the most recent. ----EEEE Pre-erase media. If this option is specified, media is erased prior to use. The operator is prompted for confirmation, unless the ----FFFF option is also specified. ----FFFF Don't prompt the operator. When _x_f_s_d_u_m_p encounters a media object containing non-xfsdump data, _x_f_s_d_u_m_p normally asks the operator for permission to overwrite. With this option the overwrite is performed, no questions asked. When _x_f_s_d_u_m_p encounters end-of-media during a dump, _x_f_s_d_u_m_p normally asks the operator if another media object will be provided. With this option the dump is instead interrupted. ----IIII Displays the _x_f_s_d_u_m_p inventory (no dump is performed). _x_f_s_d_u_m_p records each dump session in an online inventory in /_v_a_r/_x_f_s_d_u_m_p/_i_n_v_e_n_t_o_r_y. _x_f_s_d_u_m_p uses this inventory to determine the base for incremental dumps. It is also useful for manually identifying a dump session to be restored. Suboptions to filter the inventory display are described later. PPPPaaaaggggeeee 4444 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) ----JJJJ Inhibits the normal update of the inventory. This is useful when the media being dumped to will be discarded or overwritten. ----LLLL _s_e_s_s_i_o_n__l_a_b_e_l Specifies a label for the dump session. It can be any arbitrary string up to 255 characters long. ----MMMM _l_a_b_e_l [ ----MMMM _l_a_b_e_l ... ] Specifies a label for the first media object (for example, tape cartridge) written on the corresponding destination during the session. It can be any arbitrary string up to 255 characters long. Multiple media object labels can be specified, one for each destination. ----OOOO _o_p_t_i_o_n_s__f_i_l_e Insert the options contained in _o_p_t_i_o_n_s__f_i_l_e into the beginning of the command line. The options are specified just as they would appear if typed into the command line. In addition, newline characters (\n) can be used as whitespace. The options are placed before all options actually given on the command line, just after the command name. Only one ----OOOO option can be used. Recursive use is ignored. The source filesystem cannot be specified in _o_p_t_i_o_n_s__f_i_l_e. ----RRRR Resumes a previously interrupted dump session. If the most recent dump at this dump's level (----llll option) was interrupted, this dump contains only files not in the interrupted dump and consistent with the incremental level. However, files contained in the interrupted dump that have been subsequently modified are re-dumped. ----TTTT Inhibits interactive dialogue timeouts. When the ----FFFF option is not specified, _x_f_s_d_u_m_p prompts the operator for labels and media changes. Each dialogue normally times out if no response is supplied. This option prevents the timeout. ----YYYY _l_e_n_g_t_h Specify I/O buffer ring length. _x_f_s_d_u_m_p uses a ring of output buffers to achieve maximum throughput when dumping to tape drives. The default ring length is 3. ---- A lone ---- causes the dump stream to be sent to the standard output, where it can be piped to another utility such as _x_f_s_r_e_s_t_o_r_e(1M) or redirected to a file. This option cannot be used with the ----ffff option. The ---- must follow all other options and precede the filesystem specification. The filesystem, _f_i_l_e_s_y_s_t_e_m, can be specified either as a mount point or as a special device file (for example, /_d_e_v/_d_s_k/_d_k_s_0_d_1_s_0). The filesystem must be mounted to be dumped. PPPPaaaaggggeeee 5555 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) NOTES DDDDuuuummmmpppp IIIInnnntttteeeerrrrrrrruuuuppppttttiiiioooonnnn A dump can be interrupted at any time and later resumed. To interrupt, type control-C (or the current terminal interrupt character). The operator is prompted to select one of several operations, including dump interruption. After the operator selects dump interruption, the dump continues until a convenient break point is encountered (typically the end of the current file). Very large files are broken into smaller subfiles, so the wait for the end of the current file is brief. DDDDuuuummmmpppp RRRReeeessssuuuummmmppppttttiiiioooonnnn A previously interrupted dump can be resumed by specifying the ----RRRR option. If the most recent dump at the specified level was interrupted, the new dump does not include files already dumped, unless they have changed since the interrupted dump. MMMMeeeeddddiiiiaaaa MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt A single media object can contain many dump streams. Conversely, a single dump stream can span multiple media objects. If a dump stream is sent to a media object already containing one or more dumps, _x_f_s_d_u_m_p appends the new dump stream after the last dump stream. Media files are never overwritten. If end-of-media is encountered during the course of a dump, the operator is prompted to insert a new media object into the drive. The dump stream continuation is appended after the last media file on the new media object. IIIInnnnvvvveeeennnnttttoooorrrryyyy Each dump session updates an inventory database in /_v_a_r/_x_f_s_d_u_m_p/_i_n_v_e_n_t_o_r_y. _x_f_s_d_u_m_p uses the inventory to determine the base of incremental and resumed dumps. This database can be displayed by invoking _x_f_s_d_u_m_p with the ----IIII option. The display uses tabbed indentation to present the inventory hierarchically. The first level is filesystem. The second level is session. The third level is media stream (currently only one stream is supported). The fourth level lists the media files sequentially composing the stream. The following suboptions are available to filter the display. ----IIII ddddeeeepppptttthhhh====_n (where _n is 1, 2, or 3) limits the hierarchical depth of the display. When _n is 1, only the filesystem information from the inventory is displayed. When _n is 2, only filesystem and session information are displayed. When _n is 3, only filesystem, session and stream information are displayed. ----IIII lllleeeevvvveeeellll====_n (where _n is the dump level) limits the display to dumps of that particular dump level. PPPPaaaaggggeeee 6666 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) The display may be restricted to media files contained in a specific media object. ----IIII mmmmoooobbbbjjjjiiiidddd====_v_a_l_u_e (where _v_a_l_u_e is a media ID) specifies the media object by its media ID. ----IIII mmmmoooobbbbjjjjllllaaaabbbbeeeellll====_v_a_l_u_e (where _v_a_l_u_e is a media label) specifies the media object by its media label. Similarly, the display can be restricted to a specific filesystem. ----IIII mmmmnnnntttt====_m_o_u_n_t__p_o_i_n_t (that is, [hostname:]pathname), identifies the filesystem by mountpoint. Specifying the hostname is optional, but may be useful in a clustered environment where more than one host can be responsible for dumping a filesystem. ----IIII ffffssssiiiidddd====_f_i_l_e_s_y_s_t_e_m__i_d identifies the filesystem by filesystem ID. ----IIII ddddeeeevvvv====_d_e_v_i_c_e__p_a_t_h_n_a_m_e (that is, [hostname:]device_pathname) identifies the filesystem by device. As with the mmmmnnnntttt filter, specifying the hostname is optional. More than one of these suboptions, separated by commas, may be specified at the same time to limit the display of the inventory to those dumps of interest. However, at most four suboptions can be specified at once: one to constrain the display hierarchy depth, one to constrain the dump level, one to constrain the media object, and one to constrain the filesystem. For example, ----IIII ddddeeeepppptttthhhh====1111,,,,mmmmoooobbbbjjjjllllaaaabbbbeeeellll====""""ttttaaaappppeeee 1111"""",,,,mmmmnnnntttt====hhhhoooosssstttt1111::::////tttteeeesssstttt____mmmmnnnntttt would display only the filesystem information (depth=1) for those filesystems that were mounted on _h_o_s_t_1:/_t_e_s_t__m_n_t at the time of the dump, and only those filesystems dumped to the media object labeled "tape 1". Dump records may be removed (pruned) from the inventory using the _x_f_s_i_n_v_u_t_i_l program. An additional media file is placed at the end of each dump stream. This media file contains the inventory information for the current dump session. This is currently unused. The inventory files stored in /_v_a_r/_x_f_s_d_u_m_p are not included in the dump, even if that directory is contained within the filesystem being dumped. Including the inventory in the dump may lead to loss or corruption of data, should an older version be restored overwriting the current version. To backup the _x_f_s_d_u_m_p inventory, the contents of /_v_a_r/_x_f_s_d_u_m_p should be copied to another location which may then be safely dumped. Upon restoration, those files may be copied back into /_v_a_r/_x_f_s_d_u_m_p, PPPPaaaaggggeeee 7777 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) overwriting whatever files may be there, or _x_f_s_i_n_v_u_t_i_l(1M) may be used to selectively merge parts of the restored inventory back into the current inventory. Prior to IRIX 6.5.15, _x_f_s_d_u_m_p would include the /_v_a_r/_x_f_s_d_u_m_p directory in the dump. Care should be taken not to overwrite the /_v_a_r/_x_f_s_d_u_m_p directory when restoring an old dump, by either restoring the filesystem to another location or by copying the current contents of /_v_a_r/_x_f_s_d_u_m_p to a safe place prior to running _x_f_s_r_e_s_t_o_r_e(1M). When operating in the miniroot environment, _x_f_s_d_u_m_p does not create and does not reference the inventory database. Thus incremental and resumed dumps are not allowed. LLLLaaaabbbbeeeellllssss The operator can specify a label to identify the dump session and a label to identify a media object. The session label is placed in every media file produced in the course of the dump, and is recorded in the inventory. The media label is used to identify media objects, and is independent of the session label. Each media file on the media object contains a copy of the media label. An error is returned if the operator specifies a media label that does not match the media label on a media object containing valid media files. Media labels are recorded in the inventory. UUUUUUUUIIIIDDDDssss UUIDs (Universally Unique Identifiers) are used in three places: to identify the filesystem being dumped (using the filesystem UUID, see _x_f_s(4) for more details), to identify the dump session, and to identify each media object. The inventory display (----IIII) includes all of these. DDDDuuuummmmpppp LLLLeeeevvvveeeellll UUUUssssaaaaggggeeee The dump level mechanism provides a structured form of incremental dumps. A dump of level _l_e_v_e_l includes only files that have changed since the most recent dump at a level less than _l_e_v_e_l. For example, the operator can establish a dump schedule that involves a full dump every Friday and a daily incremental dump containing only files that have changed since the previous dump. In this case Friday's dump would be at level 0, Saturday's at level 1, Sunday's at level 2, and so on, up to the Thursday dump at level 6. The above schedule results in a very tedious restore procedure to fully reconstruct the Thursday version of the filesystem; _x_f_s_r_e_s_t_o_r_e would need to be fed all 7 dumps in sequence. A compromise schedule is to use level 1 on Saturday, Monday, and Wednesday, and level 2 on Sunday, Tuesday, and Thursday. The Monday and Wednesday dumps would take longer, but the worst case restore requires the accumulation of just three dumps, one each at level 0, level 1, and level 2. QQQQuuuuoooottttaaaassss If the filesystem being dumped contains quotas, _x_f_s_d_u_m_p will use _r_e_p_q_u_o_t_a(1M) to store the quotas in a file called _x_f_s_d_u_m_p__q_u_o_t_a_s in the PPPPaaaaggggeeee 8888 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) root of the filesystem to be dumped. This file will then be included in the dump. Upon restoration, _e_d_q_u_o_t_a(1M) can be used to reactivate the quotas for the filesystem. Note, however, that the _x_f_s_d_u_m_p__q_u_o_t_a_s file will probably require modification to change the filesystem or UIDs if the filesystem has been restored to a different partition or system. MMMMiiiinnnniiiirrrrooooooootttt RRRReeeessssttttrrrriiiiccccttttiiiioooonnnnssss _x_f_s_d_u_m_p is subject to the following restrictions when operated in the miniroot environment: non-restartable, no incrementals, no online inventory, synchronous I/O, no quotas. TTTTrrrruuuusssstttteeeedddd IIIIRRRRIIIIXXXX RRRReeeessssttttrrrriiiiccccttttiiiioooonnnnssss In the Trusted IRIX environment, _x_f_s_d_u_m_p must be run at the ddddbbbbaaaaddddmmmmiiiinnnn label and with the following set of capabilities: CCCCAAAAPPPP____DDDDAAAACCCC____RRRREEEEAAAADDDD____SSSSEEEEAAAARRRRCCCCHHHH , CCCCAAAAPPPP____DDDDEEEEVVVVIIIICCCCEEEE____MMMMGGGGTTTT , and CCCCAAAAPPPP____MMMMAAAACCCC____RRRREEEEAAAADDDD.... Also, the following directories and files must be labeled as ddddbbbbaaaaddddmmmmiiiinnnn : /var/xfsdump/inventory /var/xfsdump/inventory/* For example, run _x_f_s_d_u_m_p using _s_u_a_t_t_r command. #### ssssuuuuaaaattttttttrrrr ----MMMM ddddbbbbaaaaddddmmmmiiiinnnn ----CCCC """"CCCCAAAAPPPP____MMMMAAAACCCC____RRRREEEEAAAADDDD,,,, CCCCAAAAPPPP____DDDDEEEEVVVVIIIICCCCEEEE____MMMMGGGGTTTT,,,,\\\\ CCCCAAAAPPPP____DDDDAAAACCCC____RRRREEEEAAAADDDD____SSSSEEEEAAAARRRRCCCCHHHH++++eeeepppp"""" ----cccc """"xxxxffffssssdddduuuummmmpppp ............"""" If qqqquuuuoooottttaaaassss are enabled, xxxxffffssssdddduuuummmmpppp also needs the CCCCAAAAPPPP____QQQQUUUUOOOOTTTTAAAA____MMMMGGGGTTTT capability. CCCClllluuuusssstttteeeerrrreeeedddd FFFFiiiilllleeeessssyyyysssstttteeeemmmmssss In a clustered environment, a CXFS filesystem may be directly accessed simultaneously by many client nodes and a metadata server node. However, it is a restriction of _x_f_s_d_u_m_p that it may only be run on a filesystem's metadata server. With failover or simply server reassignment, a filesystem may, over time, have a number of metadata servers. Therefore, in order for _x_f_s_d_u_m_p to maintain a consistent inventory, it must access the inventory for past dumps, even if this information is located on another node. It is recommended that the inventory be made accessible by all nodes in the cluster using one of the following methods: Relocate the inventory to a shared filesystem, for example: - On the node currently containing the inventory: #### ccccpppp ----rrrr ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp ////sssshhhhaaaarrrreeeedddd____ffffiiiilllleeeessssyyyysssstttteeeemmmm #### mmmmvvvv ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp....bbbbaaaakkkk #### llllnnnn ----ssss ........////sssshhhhaaaarrrreeeedddd____ffffiiiilllleeeessssyyyysssstttteeeemmmm ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp - On all other nodes in the cluster: #### mmmmvvvv ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp....bbbbaaaakkkk #### llllnnnn ----ssss ........////sssshhhhaaaarrrreeeedddd____ffffiiiilllleeeessssyyyysssstttteeeemmmm ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp Export the directory using an NFS shared filesystem, for example: PPPPaaaaggggeeee 9999 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) - On the node currently containing the inventory, add /var/xfsdump to /etc/exports and then enter the following: #### eeeexxxxppppoooorrrrttttffffssss ----aaaa - On all other nodes in the cluster: #### mmmmvvvv ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp....bbbbaaaakkkk #### llllnnnn ----ssss ////hhhhoooossssttttssss////hhhhoooossssttttnnnnaaaammmmeeee////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp ////vvvvaaaarrrr////xxxxffffssssdddduuuummmmpppp Note: It is the /var/xfsdump directory that should be shared, rather than the /var/xfsdump/inventory directory. If there are currently inventories stored on various nodes, _x_f_s_i_n_v_u_t_i_l(1M) can be used to merge them into a single common inventory, prior to sharing the inventory among the cluster. CCCCoooorrrreeee FFFFiiiilllleeeessss If xfsdump abnormally exits causing a core dump, all its associated processes which dump core will have core file names with their extensions set to the pids of the processes. See _p_r_c_t_l(2) and PPPPRRRR____CCCCOOOORRRREEEEPPPPIIIIDDDD for further details. EEEExxxxcccclllluuuuddddiiiinnnngggg iiiinnnnddddiiiivvvviiiidddduuuuaaaallll ffffiiiilllleeeessss Occasionally it is desirable to be able to exclude particular files or directories from the dump. The ----ssss option can be used to limit the dump to a specified directory, and the ----zzzz option can be used to exclude files over a particular size. Additionally, when _x_f_s_d_u_m_p is run with the ----eeee option individual files can be "tagged" so that _x_f_s_d_u_m_p will not include them in a dump. Files are tagged by assigning that file an extended attribute with the name "SGI_XFSDUMP_SKIP_FILE". This can be done with the _a_t_t_r(1) command: $$$$ aaaattttttttrrrr ----ssss """"SSSSGGGGIIII____XXXXFFFFSSSSDDDDUUUUMMMMPPPP____SSSSKKKKIIIIPPPP____FFFFIIIILLLLEEEE"""" ----VVVV """""""" ffffiiiilllleeee To remove the attribute: $$$$ aaaattttttttrrrr ----rrrr """"SSSSGGGGIIII____XXXXFFFFSSSSDDDDUUUUMMMMPPPP____SSSSKKKKIIIIPPPP____FFFFIIIILLLLEEEE"""" ffffiiiilllleeee It should be noted that xfsdump will not check directories for this attribute. Care should be taken to note which files have been tagged. Under normal operation, _x_f_s_d_u_m_p will only report the number of files it will skip. The ----vvvv eeeexxxxcccclllluuuuddddeeeedddd____ffffiiiilllleeeessss====ddddeeeebbbbuuuugggg option, however, will cause _x_f_s_d_u_m_p to list the inode numbers of the individual files affected. If a file was tagged and skipped for a level 0 dump, and subsequently that tag was removed, the file would not automatically be included in a higher level dump. The file would only be included if it was modified since the last dump. The _t_o_u_c_h(1) command can be used on the file to update its modification time to ensure it will be included in later PPPPaaaaggggeeee 11110000 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) dumps. EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS To perform a level 0, single stream dump of the root filesystem to a locally mounted tape drive, prompting for session and media labels when required: #### xxxxffffssssdddduuuummmmpppp ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// To specify session and media labels explicitly: #### xxxxffffssssdddduuuummmmpppp ----LLLL sssseeeessssssssiiiioooonnnn____1111 ----MMMM ttttaaaappppeeee____0000 ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// To perform a dump to a remote tape using the minimal rmt protocol and a set blocksize of 64k: #### xxxxffffssssdddduuuummmmpppp ----mmmm ----bbbb 66665555555533336666 ----ffff ooootttthhhheeeerrrrhhhhoooosssstttt::::////ddddeeeevvvv////ttttaaaappppeeee //// To perform a level 0, multi-stream dump to two locally mounted tape drives: #### xxxxffffssssdddduuuummmmpppp ----LLLL sssseeeessssssssiiiioooonnnn____2222 ----ffff ////ddddeeeevvvv////rrrrmmmmtttt////ttttppppssss4444dddd6666vvvv ----MMMM ttttaaaappppeeee____1111 \\\\ ----ffff ////ddddeeeevvvv////rrrrmmmmtttt////ttttppppssss5555dddd6666vvvv ----MMMM ttttaaaappppeeee____2222 //// To perform a level 1 dump relative to the last level 0 dump recorded in the inventory: #### xxxxffffssssdddduuuummmmpppp ----llll 1111 ----ffff ////ddddeeeevvvv////ttttaaaappppeeee //// To copy the contents of a filesystem to another directory (see _x_f_s_r_e_s_t_o_r_e(1M)): #### xxxxffffssssdddduuuummmmpppp ----JJJJ ---- //// |||| xxxxffffssssrrrreeeessssttttoooorrrreeee ----JJJJ ---- ////nnnneeeewwww FFFFIIIILLLLEEEESSSS /var/xfsdump/inventory dump inventory database SSSSEEEEEEEE AAAALLLLSSSSOOOO aaaattttttttrrrr(1), rrrreeeeppppqqqquuuuoooottttaaaa(1M), rrrrmmmmtttt(1M), xxxxffffssssiiiinnnnvvvvuuuuttttiiiillll(1M), xxxxffffssssrrrreeeessssttttoooorrrreeee(1M), aaaattttttttrrrr____ggggeeeetttt(2), qqqquuuuoooottttaaaassss(4). DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS The exit code is 0 on normal completion, non-zero if an error occurs or the dump is terminated by the operator. For all verbosity levels greater than 0 (ssssiiiilllleeeennnntttt) the final line of the output shows the exit status of the dump. It is of the form: xxxxffffssssdddduuuummmmpppp:::: DDDDuuuummmmpppp SSSSttttaaaattttuuuussss:::: _c_o_d_e Where _c_o_d_e takes one of the following values: SSSSUUUUCCCCCCCCEEEESSSSSSSS (normal PPPPaaaaggggeeee 11111111 xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) xxxxffffssssdddduuuummmmpppp((((1111MMMM)))) completion), IIIINNNNTTTTEEEERRRRRRRRUUUUPPPPTTTT (interrupted), QQQQUUUUIIIITTTT (media no longer usable), IIIINNNNCCCCOOOOMMMMPPPPLLLLEEEETTTTEEEE (dump incomplete), FFFFAAAAUUUULLLLTTTT (software error), and EEEERRRRRRRROOOORRRR (resource error). Every attempt will be made to keep both the syntax and the semantics of this log message unchanged in future versions of xfsdump. However, it may be necessary to refine or expand the set of exit codes, or their interpretation at some point in the future. The message ``xfsdump: WARNING: unable to open directory: ino N: Invalid argument'' can occur with filesystems which are actively being modified while _x_f_s_d_u_m_p is running. This can happen to either directory or regular file inodes - affected files will not end up in the dump, files below affected directories will be placed in the _o_r_p_h_a_n_a_g_e directory by _x_f_s_r_e_s_t_o_r_e. BBBBUUUUGGGGSSSS _x_f_s_d_u_m_p does not dump unmounted filesystems. The dump frequency field of /_e_t_c/_f_s_t_a_b is not supported. _x_f_s_d_u_m_p uses the alert program only when a media change is required. _x_f_s_d_u_m_p requires root privilege (except for inventory display). _x_f_s_d_u_m_p can only dump XFS filesystems. The media format used by _x_f_s_d_u_m_p can only be understood by _x_f_s_r_e_s_t_o_r_e. _x_f_s_d_u_m_p does not know how to manage CD-ROM or other removable disk drives. When the minimal rmt option is specified, _x_f_s_d_u_m_p applies it to all remote tape destinations. The same blocksize (specified by the ----bbbb option) is used for all these remote drives. _x_f_s_d_u_m_p can become confused when doing incremental or resumed dumps if on the same machine you dump two XFS filesystems and both filesystems have the same filesystem identifier (UUID). Since _x_f_s_d_u_m_p uses the filesystem identifier to identify filesystems, _x_f_s_d_u_m_p maintains one combined set of dump inventories for both filesystems instead of two sets of dump inventories. This scenario can happen only if _d_d or some other block- by-block copy program was used to make a copy of an XFS filesystem. See _x_f_s__c_o_p_y(1M) and _x_f_s(4) for more details. PPPPaaaaggggeeee 11112222 
